We are today seeing a development towards a Networked Society. An increasing proportion of users' daily life is spent using telecommunication services such as telephony, instant messaging, email or accessing Internet services. Even users' personal data e.g. documents, music, photos, etc. are being stored on networked services “in the cloud”. Social networks provide communication, online presence and document sharing. Both public and private sector companies rely on telecommunication and cloud services for increasing amounts of their business. Security and privacy for users and enterprises is therefore increasing in importance. Particularly important aspects are authentication and data encryption.
Services provided by a traditional (mobile) network operator are considered to have a high level of trust. The services are usually well protected against third parties using strong, SIM-based authentication and data encryption. Thus, security is also transparent to the user. For services provided “over the top”, e.g. Internet services, the situation is very different. The security provided is typically based on user name and password, making the solution cumbersome for end-users and relatively insecure due to the difficulty of managing strong passwords.
In order to facilitate the provision of services (such as operator provided or over the top services) to user terminals, a mobile network such as a 3G network can provide for the establishment of a secure communication channel or “security association” between client terminals (i.e. mobile terminals) and the service nodes which provide the services. The Generic Bootstrapping Architecture (GBA) defined in the 3GPP Technical Specification TS 33.220 V11.4.0 (2011-12) provides a mechanism whereby a client terminal (UE) can be authenticated to a Network Application Function (NAF) (i.e. an Application Server), and secure session keys obtained for use between the client terminal and the NAF. FIG. 1 illustrates schematically an example of the simple network model for the GBA, as described in 3GPP TS 33.220, which comprises a Bootstrapping Server Function (BSF), a Network Application Function (NAF), a Subscriber Locator Function (SLF), a Home Subscriber System (HSS) and the User Equipment (UE). Communication between the NAF and the UE takes place over reference point Ua, communication between the NAF and the BSF takes place over reference point Zn, communication between the UE and the BSF takes place over reference point Ub, communication between the BSF and the HSS takes place over reference point Zh and communication between the BSF and the SLF takes place over reference point Dz.
When the UE wishes to contact a NAF and no security association between the UE and the NAF has been established at an earlier stage, the UE may contact the NAF with a request for communication and the request may not include any GBA-related parameters. If the NAF requires the use of a security association obtained by means of the GBA, the NAF may respond to the UE with a bootstrapping initiation message. The UE will then start a bootstrapping procedure with the BSF. The GBA provides a mechanism to bootstrap the Authentication and Key Agreement (AKA) for application security from the 3GPP AKA mechanism described in 3GPP TS 33.102. This mechanism allows a UE to be authenticated to a BSF and to obtain a master key (Ks) and a Bootstrapping Transaction Identifier (B-TID). GBA User Security Settings (GUSS) is a set of all user security settings and is stored in the HSS. During the bootstrapping procedure, the BSF obtains the GUSS from the HSS. The bootstrapping procedure is indicated in FIG. 2 as step 2.1.
The master key Ks is shared between the UE and the BSF, but not with the NAF. Instead, an application specific key Ks_NAF is derived by the UE. The derivation of Ks_NAF is performed by a key derivation function (KDF), defined as KDF(Ks, “gba-me”, nonce, IMPI, NAF_id). The term “nonce” is used here to indicate an arbitrary number that may be used only once in a cryptographic communication and which may help to defend against replay attacks. Ks is the master key defined earlier; “gba-me” is a fixed value; nonce is a nonce (an arbitrary number used only once in a cryptographic communication) used to generate Ks; IMPI is the Internet Protocol Multimedia Private Identity of the UE; and NAF_id is the NAF identifier of the NAF. The NAF_id is constructed by a concatenation of a Fully Qualified Domain Name (FQDN) of the NAF and a security protocol identifier of reference point Ua. The derivation of Ks_NAF is described in 3GPP TS 33.220 and indicated in FIG. 2 as step 2.2.
The UE then supplies the B_TID to the NAF over reference point Ua in an application request. This step is indicated in FIG. 2 as step 2.3. After receipt of the application request at the NAF, the NAF determines the NAF_id and verifies that the user is authorized to use the NAF_id, as indicated by step 2.4.1 in FIG. 2. The NAF then sends an authentication request including the B-TID and the NAF_id to the BSF over reference point Zn, as indicated by step 2.4.2 in FIG. 2.
On receipt of the authentication request, the BSF looks up the master key Ks using the B-TID and the BSF derives the application specific key Ks_NAF using the KDF and the NAF_id supplied by the NAF. This step is illustrated as step 2.5 in FIG. 2. The BSF sends an authentication answer including the Ks_NAF back to the NAF, as indicated by step 2.6 in FIG. 2. The BSF may also include other information, such as the bootstrapping time and the lifetime of the key, in the authentication answer to the NAF. If the key identified by the B_TID is not available at the BSF, the BSF will indicate this in a reply to the NAF and the NAF will then send a bootstrapping renegotiation request to the UE.
The NAF and the UE now both know the value of Ks_NAF and they can use that key to protect communication (step 2.7) between the NAF and the UE over reference point Ua. This protection may comprise e.g. encryption and/or integrity.
The UE comprises a mobile equipment (ME), and a Subscriber Identity Module (SIM or USIM), which may be contained on a Universal Integrated Circuit Card (UICC). The calculations in the UE involved in the above process may take place in processors of the ME (GBA_ME) or the UICC (GBA_U), with possibly different parts of the calculations being spread across these entities.
The above process provides strong security and can be made more or less transparent to the end user.
This bootstrapping architecture enables mutual authentication and key agreement between the UE and the NAF. However some NAFs may need verification beyond that provided by the network, for example to authenticate the user behind the UE, or a third party device to which the UE is connected. This problem is not tackled by the GBA architecture, which only authenticates the UE (more precisely, the SIM/USIM).
Another issue is that in a GBA-based solution, the mobile operator has knowledge of the key between the UE and the NAF, and so can potentially access communications. This is normally not a problem as mobile operators can be considered trustworthy. However, in some use cases such as mobile health, banking, or access to other high value content, there may be regulatory requirements or privacy concerns which forbid the use of protocols which might allow any third party to access communications. Also, if an attacker gained access to keying materials from the HSS, they would then be able to decrypt future communications using keys derived from those materials.
Previous attempts to authenticate a user and a device simultaneously have had the disadvantage that they require disclosure of the user's secret to the BSF (or some other server controlled by the mobile network operator), which is clearly undesirable if the wish is to prevent the network operator from being able to access communications. Examples include the US patent application “Secure Bootstrapping Architecture Method Based on Password-Based Digest Authentication” US 2011/0145575 A1, and 3GPP TSG SA WG3 (Security) meeting #64 contribution S3-110649, which deals with integrating the OpenID system into an AKA-based method.
These problems can be mitigated by the use of a secondary authorisation protocol within the secure connection established by the GBA; however the extra signalling required can slow down the authentication process, making it more time consuming for the user. Otherwise, the UE can authenticate the user locally (i.e. without contacting any server), and only perform the GBA authentication once the local authentication has been established, for example SIM cards can be configured to require confirmation of a PIN shared between the SIM and the user before they will authenticate with the mobile network. However, it is generally preferred to verify passwords on the server side instead of locally on the device, as it makes the server authentication more resilient to attacks which may be able to fake the local authentication.